查看原文
其他

从 Adobe 和 Sketch 中突围,Figma 走对了哪三步? | Startup Recipes

Startup Recipes Founder Park 2023-12-30

200 亿美元,Adobe 收购了设计协作平台 Figma,创下了 C 端 SaaS 领域的估值记录。

不去讨论 Adobe 为什么去收购 Figma,我们今天转载的这篇 2020 年的文章,主要是分析为什么 Figma 能取得成功,为什么在 Adobe 和 Sketch 已经成为主流的情况下,Figma 能够成功;Figma 到底做对了什么?对于今天的诸多创业公司来说,这些分析仍然是有价值的。

本文作者 Kevin Kwok,创投公司 Greylock Partners 前合伙人,当年在投资 Figma 时负责尽职调查,对于 Figma 的业务模式很熟悉。

编译来源:Why Figma Wins
作者 | Kevin Kwok
翻译 | hite 和落雁
转载自:公众号「小集」,转载时有修改。


  1. Figma 的第一阶段成长是「用新技术解决设计协作痛点」。在 Figma 以前,设计人员之间的协作发生在本地,所谓的「云端」只是档案上云。Figma 利用新技术改变上述的老旧流程,让编辑、储存、分享全部都发生在浏览器和云端。

  2. Figma 的第二阶段成长是「打造跨边网络效应」。将设计作业流程全部搬上云端的破坏力非常高,不单单只是取代掉 Sketch、Dropbox 等工具,更改变组织内的沟通流程。过去,非设计部门的人不论想在哪个阶段参与设计流程都非常困难;透过 Figma,大家可在同一个环境中进行讨论与修改。Figma 不再只是设计师圈使用的「工具」,而是凡与设计有关的人都得加入的沟通「标准」

  3. Figma 的第三阶段成长是「成为一个平台」。当超过一定规模以后,任何工具都无法再凭一己之力满足所有使用者者,此时不是舍弃这些不满足的使用者、任其成为后继新创的成长养分,就是得成立开发者社群、由一般人协助开发扩充功能。


公司的成长是某种循环的序列,一些长期成功的公司往往能不断的寻找到自身成长的下一个循环。然而,相对于这些循环带给公司发展轨迹的影响,人们对这种循环演变知之甚少。Figima 就是这样一个不断循环发展的例子,人们普遍认为它是成功的,但是它成功的关键原因,以及 Figma 的管理层做了哪些决策使得他们能够进入下一次循环,却少有人知。

Figma 增长示意图

Figma 的核心理念是设计不仅仅局限于设计师。设计是设计师关于如何构建业务,和项目经理们之间的对话,并且根据他们的反馈做出原型的过程。Figma 提供了大量的规范和素材,让工程师们的实现变得容易。这个流程让设计师在公司在做出核心决策时能够参与其中。

在设计过程中,为所有人设计(而不仅仅是设计师)是 Figma 核心循环的基础,它驱动了 Figma 的成长和规模复合式增长。它的网络效应得益于 Figma 早期的一些决策,比方说:

  • 浏览器优先,不仅仅是把数据存在云端

  • 新技术的引入。Figma 很早引入了 WebGL 和 CRDTs* 技术,让浏览器的体验媲美客户端应用(如 sketch)

  • 专注矢量图形、数字产品设计

CRDTs:conflict-free replicated data type (CRDT) 是来自分布式计算领域的概念,Figma 用它来解决多人协作编辑同一个文档时如何处理冲突、和同步数据的问题。目前在线编辑文档常用的算法 - Operational Transformation 算法是其中一个变种。

Figma 的复合式增长不仅仅得益于产品市场的增长,发行渠道和产品对齐也是重要的驱动力。如果 Figma 仅仅在公司的内部流行和传播,那也不会如此成功。为了突破增长天花板,Figma 在整个生态系统上建立一个全球的网络效应。随着 Figma 的流行,对很多新用户而言,它的价值在成倍增长。

Figma 押注于把自身打造成为一个平台——围绕着社区和插件系统。虽说现在刚刚起步,但它的效果已经依稀可见。

许多的公司处于这样一个拐点——他们发现自己的核心产品是成功的,同时还在尝试把产品价值推动到下一个阶段和规模。从如何在公司的核心业务和其潜在的未来扩张之间进行资源配置,到如何构建一个平台加速公司增长等,在规则被搞清楚之前,它更像是门艺术而非科学。这里有许多决策要做,包括哪些层面要集中控制、生态系统是否应该由开源的贡献者或者逐利的企业来推动、如何控制生态系统的增长范围以及产品不应该发展的方向等。




01

扩大协作范围

当 Figma 第一次发布的时候,它的主要价值体现在如何让设计可以协同。通过浏览器,设计师可以在相同的工程里做设计,甚至于对同一个设计稿同时编辑,这就很强大了。

在 2014 年,我作为 Greylock 工作人员参与对 Figma 的投资调查,曾经和创业公司的设计师们坐在一起,观察他们的工作。在他们的屏幕右上角,Dropbox 的更新通知一直闪动。因为设计团队把所有的文件都放在了如 Dropbox 这样的共享文件夹里,但凡有一名同事修改了文件,其他人都会收到通知。文件名称一般都很复杂,这样能确保人们使用的是正确的版本。

Figma 解决了这个问题,在 Figma 里的设计稿不仅仅存储在云端,而且还可以在云端编辑,这意味着 Figma 的用户始终在相同的设计稿上工作。使用 Dropbox 做不到这点——它仅仅是把视觉稿保存在云端,但编辑是在本地进行。想象一下,大概类似于在 Dropbox 中共享 Word 文件与在 Google Docs 中编辑的区别。

在 Dropbox 中,当用户编辑一个设计稿时,他们实际上是在一个临时复制的视觉稿上做修改,这就是为何两个用户同时修改一份视觉稿会产生冲突的原因。在 Figma 里编辑设计稿,你不会遇到冲突。取而代之,Figma 用版本号来标示每一次修改。再也没有必要遵循特定的复杂的文件命名了,如 profile_design_v23_final_draft2。更进一步,设计师可以直接在 Figma 的设计稿上发表评论,而不是通过邮件来进行互动。

云存储和在线编辑的区别,循环少的更好。

我一度很疑惑为何 Figma 团队一直坚持要做浏览器优先,它和云端优先的区别是什么呢?随着时间的推移,我逐渐认识到这一区别的重要性。当许多有创意的工具公司谈到云时,他们似乎把它看作是用来存储文件的地方,而最基础的用户创作体验却是在一个独立的桌面程序上完成的。Figma 以浏览器优先,他们率先使用最新的 web 技术,如 WebGL,Operational Transforms 和 CRDTs,使得在云端编辑也有很好的使用体验。

从用户的角度来看,在和别人协作时,再也没有文件和同步的概念,非常方便。用 Figma,实际的「设计体验」都是原生在互联网上的。甚至到今天,有些竞争对手谈到云时,依然还在争论要把多少功能迁移到互联网上。正确答案是:所有的功能。

设计师们喜欢 Figma,是他们推动了最初 Figma 的流行。Figma 的特色功能,诸如团队库,让这批用户把更多团队里的设计师拉进 Figma 的用户大军里。但是设计师对 Figma 的热爱(它确实是成功的先决条件),并不能完全概括 Figma 如此吸引人的根源。Figma 在为设计师创造理想工具的同时,他们也创造了很多更重要的事情——把非设计师也纳入设计流程。

Figma 带来了不同的设计沟通流程。

1.1 

做设计工具,

但不仅仅为设计师而做

当 Figma 在创造更好的设计工具的同时,他们浏览器优先的策略也对非设计师产生了更激进和重要的影响。

我们常常会忘记,我们在工作中使用工具的目的,并不是去提高个人的生产效率,而是整个团队的效率,很多公司常常忘记这一点。

对个人来说最好的工具可能对团队来说也是最好的,但后者更重要。除了提高个人生产力之外,团队协作也越来越重要。文字处理是一个很好的例子,过去有很多围绕着个人功能的开发,比如排版,而一旦功能足够好了之后,关注点就会转移到协作。如今已经很少有人关注排版问题了,更在乎的是我们的工具必须能够理解,并且和其他人协作方式保持一致。人们的工作很少单打独斗了——所以使用的工具也必须能够反映这一点。

最好的设计工具可以多人协作——这是以前无法想象的。

历史上,让非设计师参与到设计过程是非常困难的。如果 PM、工程师、甚至是 CEO 想参与进来,在流程上有很多阻力。如果他们想要整个设计稿,设计师需要先把文件发过去。然后对方需要先下载下来,还需要电脑上安装了合适版本的 Adobe 或者 Sketch,这些工具对于那些不经常使用的人来说是很麻烦的:购买太贵,并且这些工具都很大、运行缓慢、学习曲线陡峭。没有设计师的指导,很难去很好查看整个项目。关于文件的评论互动需要使用邮件,更糟糕的是,如果设计师修改了视觉稿,接收者之前拿到文件其实是过期的——查看的人并不知道有更新。

整个过程中,设计师的体验同样很糟糕,如果他们希望 PM 和工程师能够给一些反馈,他们需要提前多做一些准备工作,把视觉稿导出为图片,发送截图,之后再把其他人的反馈修改到设计稿里。这个反馈循环运行得太慢,以至于往往会卡在等待别人的反馈上面。

当然,在实际场景里,大部分时间里非设计师在设计过程中,参与的程度远远不及设计师。评审视觉稿的痛苦并不是这个过程里最主要的问题,因为整个过程中太多的摩擦,往往不会有评审视觉稿的环节。

Figma 解决了上述的所有问题。

用 Figma 分享视觉稿只需要发送一个链接。任何人都可以直接在浏览器中打开它。这就像随便打开一个网站一样简单(实际上就是打开了一个网站)。一旦有了链接,非设计师总是获取到最新的视觉稿。他们可以直接在视觉稿中进行评论,而不会干扰设计师的流程。通过协作编辑,他们可以在会议中讨论修改意见,并实时观看意见的执行情况。

这些技术变革引发了一个更重要的社会规范的改变。Figma 让非设计师尽早参与设计过程,并且全程参与。

Figma 让很多公司意识到,非设计师应该也可以更多地参与到设计过程中来,而其他设计工具居然完全没有考虑到非设计师使用设计工具的体验,差距太明显了。

1.2 

更紧密的反馈

Figma 拉近了设计师和非设计师之间的距离,也对团队交流的流程产生了重要的影响。历史上,常常在设计介入的时候,因为设计过程中的各种阻力,很多的业务决定已经做出了。反过来说,一旦设计完成,非设计师对设计的影响也非常的有限。

更紧密的反馈循环在过程中引入非线性的反馈。设计草稿可以和产品一起进行,设计和产品之间的双向反馈贯穿始终。设计中用到的素材提前和开发沟通好,在交付视觉稿时无缝衔接,避免失真,迭代沟通更方便。

所有交流都可以基于 Figma。

设计师可以从团队里的 PM 和工程师里持续获取反馈。有些人对于非设计师过于深入到设计过程感到很敏感、不安,但这和设计师从中获取到的好处相比,这个代价微不足道。

把非设计人员纳入到设计过程,可以让设计师在产品和商业决策中拥有话语权。

长久以来,我们系统地将设计、销售和客户服务等流程孤立起来。但是,越来越多年的公司意识到,如果核心循环是一个迭代的过程,像设计这样的职能部门本身必须成为公司反馈的一部分,设计不能单独抽离出来。

历史上,设计在整个商业活动中常常隐形,因为设计想做的对其他人清晰可见,在逻辑和技术上存在困难。但是随着这些困难被像 Figma 这样的公司慢慢解决之后,我们看到越来越多的公司把设计作为整个公司决策流程中的重要一环。这并没有大惊小怪的,因为在过去的几十年里,我们已经在工程领域看到了同样的趋势已经发生。


02

更多增长方式

目前 Figma 取得的成功很大的原因是它可以在公司内部快速传播,一个公司越多的人使用,它的价值就越大,最后形成公司内部统一的规范。

Figma 很快意识到在公司里做设计最大的限制不是像素而是人。很多 Figma 的竞争者对设计师而言是伟大的工具,但也只限于此。相比之下,Figma 是一个团队的设计工具,不仅仅是设计师一个人的工具。

Figma 是为团队服务的设计工具。

通过把设计师和非设计师都带入到 Figma 的工作流里,他们创造了一种跨界的网络效应。

在内部的网络效应里,越多的人参与到组内,组内的其他人得到的价值就越大。相反,如果是跨界的网络效应会牵扯到两个(或者更多)不同的组织,他们在规模和价值方面都有同步的增长。

Figma 在设计师和非设计师之间的跨界网络效应是他们过去几年来复合式成功的主要和被低估的原因之一。

看着越来越多的设计师使用 Figma,他们会吸引与他们一起工作的非设计师。同样,当这些非设计师使用 Figma 时,他们会鼓励与他们一起工作的其他设计师使用 Figma。这是一个良性循环,一个强大的复合式增长循环。

2.1 

跨界网络效应

跨界的网络效应没有直接的网络效应那么显眼,一部分原因是我们描述网络效应的词汇缺乏张力,但主要是因为它们通常被认为是专门针对市场的。跨界的网络效应在市场里很常见,但并不是只存在于市场。供给和需求是最著名的跨界网络效应,但不是唯一的来源。

Figma 早期的直接网络效应帮助他获得早期的用户设计师,但是对于 Figma 快速扩张却有一些很固有的缺陷。一个设计师直接接触的设计师是有限的、不容易变化,虽然可以通过口口传播和社交媒体触达很多其他设计师,但是这种方式有自己的天花板。

Figma 的跨界网络效应提供了一个额外的方式。使用 Figma 的设计师与工程师和项目经理分享他们的设计,并向他们介绍 Figma。当这些非设计师学习认可 Figma 后,他们就会把它传播给其他从事不同项目的设计师团队。这些跨界网络效应跨越团队,帮助 Figma 在整个组织中广泛采用。

跨界循环的次数越多越好。

这也会影响公司的财务和采购决策。因为一个新的设计工具为设计师提供了新的功能而采购的需求,可能不会被优先得到支持。但如果产品经理,工程师,甚至是 CEO 自己都认为这对整个企业很重要,那么它就有更高的优先权,被认为买得物超所值。

2.2 

产品分销配合

Figma 的网络效应推进了 Figma 的快速成长。就像播种,Figma 能从一个很小公司的个别人开始使用,每个人都能引起整个公司的快速扩张,最后被广泛使用。一旦 Figma 被一些设计师采用,他们跨部门的所有同事就会接触到这个产品。一旦他们被它的协作特性吸引,他们也会鼓励在其他团队和项目中采用它,等等。

这正是 Figma 能得以复合式增长的秘诀。

Figma 产品的核心正是它分发渠道的核心。这是非常稀有和强大的竞争力,真正产品和核心分发网络的一致性,催化外部人员爆发式复合增长。

像这一代公司中的许多同行一样,Figma 制定了两步销售计划:落地和扩展。自下向上的以产品驱动落地,当产品习惯一旦转移为 Figma,开始自上向下的销售。为此,企业需要准备一堆的产品亮点,建立起强大的销售机器等等。在过去的许多年,Figma 已经初见成效,但依然还有很多工作需要他们去做。

产品销售循环

这是一种新型的企业,集合了产品驱动、消费者增长驱动、销售驱动型的混合体。我们依然不知道如何去仿照它的组织结构、产品的进入市场策略、定价模型来适配自己的公司。就像之前的 SaaS 一样,这种自上而下或者自下向上的模式需要花很多年从艺术变成成熟的科学技术使用。尽管 Figma 在增强传统企业销售流程方面还有很多工作要做,但如果他们仅仅停留在简单地重新创造传统企业销售流程上,那就太令人失望了。从业者们也逐渐明白:这些销售循环可以像增长循环一样被理解。通过产品、运维、也有许多方法可显著提高销售速度和加快规模增长。Figma 是这方面最前沿的公司之一。


03

建立生态系统

Figma 的下半场在哪?

现在的产品总有需要改进的地方,但不能一直对它更新,是时候考虑下,Figma 下一步成长循环增长点在哪里?

向上走还是向右走,总得选择。

竞争格局日渐白热化,竞争对手开始抄袭并蚕食 Figma 的核心优势。当这些竞争者慢慢进入到 Figma 的领域后,Figma 感受到了压力并迫使他们继续向前。例如 Sketch,它已经把自己的定价模型改为订阅制,面向团队协作,并聚焦于把越来越多的产品转移到 Sketch Cloud 里。去年,他们接受 Benchmark 一笔融资,在此之前,他们一直自力更生。这笔资金支持 Sketch 沿着 Figma 的方向紧追慢赶,特别是让 Sketch 可以在浏览器里运行和团队协作。

Adobe 也有类似的举动,Photoshop 和 Illustrator 虽然功能强大,使用广泛,但并不是数字产品设计师的专门产品。在 2019 年,他们已经发布了 Adobe XD 作为 Figma 和 Sketch 的对标产品。

过去几年,Figma 一直专注于其在公司内部的价值和传播。Figma 的下一个挑战是提高其在整个生态系统中的价值和传播。

3.1 

全球网络效应

通过跨界的网络效应,使得 Figma 在公司内部快速传播,但是如何传播到其他公司呢?

看 Figma 的增长率,它确实是在增长,但少了些复合的增长趋势。许多人是跨公司工作,尤其是一些代理商,会传播 Figma 给他们的客户。类似的,当这些人离职进入到下一家新公司时,他们也将 Figma 带入到新公司。当然口碑也对它的传播起很大的帮助。

对于那些已经在使用 Figma 的公司而言,新注册一个账号的作用要更大,相比公司里没有人用 Figma 而言。因为已经有很多同事在使用它来协作了。每个公司都有一些特有的视觉素材和设计库,这些组件可以在各个同事之间复用。但是对于没有同事使用 Figma 的公司来说,这些价值都是不存在的,他们还是习惯于传统的本地方式,还没有享受到 Figma 所带来的便利。

Figma 的挑战不仅仅在于在公司内部创建本地网络效应,还需要创建全球网络效应,使其伴随着 Figma 自身规模增加同时,带给所有用户更多的价值。他们有很多方法来扩展他们的规模,但本文只关注他们已经采取的方式。

在 2019 年,Figma 为跨公司之间的生态系统成长种下了种子。随着他们去年 8 月发布的 Figma 插件和最近发布的社区,他们开始把推动跨公司协作和生产力提升作为最优先的任务。

3.2 

通过社区增强创造力

允许用户和公司公开分享他们的设计,使社区进一步推动网络效应的发展。历史上也有一些网站可以分享设计作品,比方说 Dribbble,它的问题是,大部分的分享是视觉稿导出的图片。对其他人来说,很难看到整个设计全貌,包括图层、内部使用的组件等。即使是你分享了设计稿的源文件,解决用什么工具打开它和解决文件的依赖也不是小事。

通过 Figma 分享设计稿解决了这些麻烦的事情,任何人能立即打开文件,并且立刻在自己的工程里引入此文件。这使得用户也可以毫无障碍地成为创造者,而不仅仅是消费者。

很多设计师通过 Github 来分享他们的 UI Kit、组件库和设计系统,想法是对的,但是 Github 不是给设计稿做的。Fork 一个仓库对工程师很简单,但对设计师却不见得那么容易。在设计方面,Github 更类似于一个用于下载文件的托管站点。如今在 Figma 社区在很多方面都继承了 github 的理念,但始终考虑为设计师设计。复制一个共享视觉稿,一个副本会立即保存到您的工作空间中,并可以随时编辑。

视觉稿的接收者不必等最终的视觉稿定稿,即可以查看设计素材底层应用的组件,也可以看到围绕设计稿所做的复杂交互和动画。

一个很好的例子,就是 Figma 的设计总监 Noah Levin 分享的 Figma 的智能动画。通过与社区分享整个设计,其他人不仅可以看到动画,还可以直接使用和调整参数研究它。这使他们更容易学习如何使用智能动画,甚至只是复制部分 Levin 的演示到他们的设计中。

3.3 

插件的使命

我用 Figma 做过非常有趣的梗图发给我的朋友。Figma 很好,但是当我开始在文字后面加一些带颜色的矩形图案(当然是圆角——我不是一个没文化的人)使文字更易读后,我变得烦躁起来——它是一系列很小但是需要死记硬背的烦人步骤。最近我发现插件 Substrate for Text 可以简化上述制作过程。现在我只需要选中文字,激活插件,文字背景色立刻生成好了。这个插件的作者是个设计师,Andreslav Kozlov,他生活在俄罗斯。在世界的另一边,Andreslav 也遇到了同样的问题,他写了一个插件来解决这个问题,通过网络分享给别人。

这是一个关于插件的使命的很小的例子。插件让 Figma 变得可扩展,让设计师改进他们的工作流,获取新的能力,并且相互之间分享插件。

插件的作用

大部分的插件简化了那些重复的、让人感到痛苦的任务。如今,一些公司创建了一些私有的插件满足他们定制化的需求。例如,自动生成暗黑模式的设计稿,抓取外部数据填充,或者检测那些通用的设计错误,或者自动生成正确朝向的素材等等,这些插件提升了整个团队的生产力。

插件真正的力量是让这些插件能够跨整个生态系统公开使用。插件是所有用户集体的福利。无论你创建的插件图表、自定义地图,、给你的设计稿填充数据,、加快给工程师交付,、或者随机水滴等,插件提升了所有设计师的效率。譬如 Figma Chat 之类的插件表明,通过为设计师提供一种全新的能力,Figma 还可以变成你完全不敢想象的样子。

随着公司的发展,持续为客户提供一贯的价值增长变得困难。随着客户增多,一个公司做的产品很难满足所有独立的用户个例和需求。当公司的业务扩展到核心客户之外,它们也必须越来越多地为不太理想的客户提供服务。插件帮助 Figma 减轻这种不协调。当用户变多时,插件也变多了,为新用户提供更好的产品,并刺激创造更多的设计。

3.4 

打造一个平台

例如 Sketch 这样的公司已经展示了一个健壮的插件系统的重要性(当然,Adobe 在他们之前就鼓励 Adobe 产品使用插件)。一个公司要想为每个用户都提供他们所需要的特性是不可能的。当遇到的案例增长、多样性大于一个公司所能提供的时候,急需要平台的出现。Sketch 的插件带给用户的价值增长大于 Sketch 自身发布新特性带来的增长。Figma 也专注提供最核心的特性,和用户工作流相关的领域留给插件平台去满足。

借助插件满足用户需求

在如何成为平台上,大部分公司的理解都很早期。越来越多公司都触达了创建平台的临界点,平台是个优先的任务,但是大部分又在各自重复造轮子。10 年后,将会有一些纯粹的框架、指标、支持性的生态系统来创建平台,但现在很少。这是一种自然的规律,所有的业务模式都经历过成熟阶段,例如过去十年的 SaaS 和订阅的成长。

商业模型发展太快了。

因为我们缺少共识的词汇来描述创建平台,所以对很多人来说,很难理解不同公司采用的策略之间细微而又重要的差别。你可以很简单的假设所有插件系统都是一样的,但这通常是不正确的。

3.4.1 

Sketch:个案分析

说到 Sketch 的插件系统,它的文档很完整,插件的种类也很全。但是插件不属于 Sketch 产品的核心。用户常常直接去 Github 的下载页安装插件,大部分是手动下载、安装。即使 Sketch 放在云端,但是它的插件却是本地文件。下载、安装插件耗费精力,当在一个团队里确保所有人都使用相同的插件时,配置工作量几乎要翻倍。

因为插件在 Sketch 内不是优先功能,被排除在核心范围之外,插件的管理是非常分散的。插件可以注册在 Sketch 的网站上,开启自动更新,但是 Sketch 的管理非常宽松。没有一个官方的来源展示一个插件的流行度,插件上线也不需要得到审核通过。取而代之,用户依赖 Github 上的星标数和第三方网站上的评论来判断插件质量。也没有对带来性能或稳定性问题的插件的监督。

这其实不是批评。Sketch 插件架构的弱点之所以显示出来,只是因为他们在鼓励 Sketch 强大的插件社区方面取得了足够的成功。

平台是最近涌现出来的生态系统,它更像是去创建一个消费者的社交网络,而不是传统的企业销售公司。这是构建平台的核心困境之一。他们是复杂的有机系统,需要精心培育。很难去提前预测说平台向哪个方向发展,能达到多大的规模。

Sketch 或许不应该被指责。直到今天,我们依然不知道插件能做哪些、应该做哪些功能。通过采取相对不干涉的方式,他们允许社区不受他们的干扰而繁荣发展。正是因为看到了 Sketch 在插件方面的成功,以及他们的挣扎,其它公司如 Figma 和 Adobe XD 对插件系统的重要性、潜力、杠杆能力才越来越有信心。

虽然 Sketch 不能被指责,但他们的很多选择已经阻碍 Sketch 围绕插件发挥出全部的潜力,这一点 Sketch 是知道的。他们重构了整个插件系统,整个迁移到云端,这是向正确方向前进的必要一步。

3.4.2 

Figma:奠定基础

Figma 的插件刚刚起步,但是很有前途。系统内置和浏览器优先,当你点击安装插件的时候,它立即就可用了。除了需要激活几个权限,没有多余安装步骤。

不同的安装步骤。

像所有成功的魔术一样,让安装插件如此简单背后需要付出很多艰辛的工作。Figma 的插件必须安全、高性能、稳定。特别是为一个浏览器优先的系统构建时,上述原则更加重要。用户应该可以相信插件,不必担心使用插件会让他们暴露在安全风险下,或者影响到 Figma 的性能。开发者和用户都应该相信他们使用的 API 不会突然过时或者坏掉了。没有这些前提条件,插件只是 Figma 里的一个小部分。信任和稳定性是健壮生态系的基石。

不同的插件体系。

从 Figma 工程师的 blog 中我们看到创建插件系统有多困难。有一个月的时间,他们的文章都是关于如何确定插件系统的架构。他们最后发现自己的方案有漏洞,不得不调整了方向。

确保平台是可信任的不仅仅是技术架构的事情。Figma 不仅仅是托管插件,他们有一个中心化的审核流程——更像是 Apple 的 Apple store Revuew 那种。插件要想被收录,必须通过 Figma 在安全性、商业、可用性和合法性方面的审查。

3.4.3 

平台化之路

商业化政策特别值得一提。安全、可用、合法维持了插件系统的完整性和可信任,Figma 的商业政策塑造了他们认为插件生态应该是什么样子的。例如,他们允许插件可以收费,但更推荐对所有用户都可用。在鼓励形成一个商业插件生态系统和更面向开源社区之间,权衡哪方应该支持更多些是没有正确答案的。常常需要随着平台的成长而调整。只要在一段时间内观察 Uber 司机、WordPress 插件或者 Airbnb 房东的构成就能明白了。

平台和开发者的关系。

构建一个平台需要做很多类似上述艰难的决定,你该如何平衡现阶段的增长和为长远理想目标工作的矛盾?平台应该多大程度上影响哪些插件应该被创建,亦或决定在早期哪些插件应该被创建?如何确定哪些功能特性应该平台内置还是应该由单独的插件来实现?插件功能可以在多大的范围被允许创建?这些只是核心问题的其中几个而已。

也许 Figma 最有趣的关注点是如何让创建插件更容易。Figma 的插件系统特别的为设计师转化为开发者而设计,鼓励设计师自己为自己的工作流写插件。在大部分的平台和市场、生态系统,随着时间的推移,都倾向于分裂和专业化。这是生态系统的自有重力导致的。去下注于个人对自身工作流的改进会提升整个平台的影响是一个大胆的想法。这是对诱导需求的押注。

Figma 的插件生态系统发展刚起步,从他们已支持功能列表和计划要支持的功能来看,他们还依然有很长的路要走,提升平台的开放程度,以引入更高级的插件。为插件系统选择合适的抽象层是非常关键。到目前为止,对于围绕安全性、性能和稳定性需要做出的核心技术决策和承诺,他们采取了非常强硬的立场,但对构建什么插件却毫不干涉。当不清楚应该创建哪些插件时,放手看社区的创意会向哪个方向发展,不妨是个不错的政策。这通常会带来迷人的东西。随着时间的推移,我们期望看到 Figma 更多的关注点,但是如今,他们的插件页面除了流行度和特色插件外是没有排序的。当插件数量不多的时候,还可以用,到最后他们还是得决定所有插件分类和设计发现页应该做成什么样子。

随着插件分类越发清晰,Figma 需要对插件有更明确的观点:哪些插件的功能应该吸收到核心产品里;当插件系统成熟后,每个分类应该看起来是什么样子;哪些必需的插件还没有出现,他们需要催化他的产生;哪些新的 api 应该被引入供插件使用等。

多大程度去鼓励插件系统的商业化,正如上面讨论过的,是 Figma 需要作出的关键决定,在他们创建插件平台的时候,需要反复的做类似的关键决定。

也许对 Figma 最重要的是,他们需要确定做决策的元框架,保证所有的决定是一致而不是来自某时的突发奇想。


04

推动进步的发生

设计一直在进步吗?我们是否在设计方面越来越好,不是作为一种艺术,而是作为一种功能实践?

答案当然是 YES。我们有 10 年前根本没敢想过的工具,更不要说是没有计算机之前的工具。容易设计,容易开始设计,设计变得有扩展性。

但是和工程师们在流程上改进的比率相比,设计流程改进的比率如何呢?设计作为一种元过程,在这些基准测试中的成绩并不是很好。

在使自身商品化和推动流程进步的速度方面,工程技术几乎是无与伦比的。框架、语言和基础设施中的最佳实践总是快速地、甚至是剧烈地演进着。以前需要整个团队才能做的事情,现在只需要越来越少的人就可以完成。

随着学科的发展,他们找出了更好地运作所需的社会规范,建立了可以在整个行业共享的工具,并发明了允许减轻越来越多工作量的概念。他们学习到如何更好地协作,不仅仅和其他人协作,也在于和其他功能一些协作。原则对他们而言不是重点:他们对更大的组织和生态系统的贡献程度是衡量他们工作的最终标准。

设计似乎在向工程化的方向发展。Figma 处于这次变革的前沿。作为一个工具,Figma 打破了设计师和与他们一起工作的其他团队之间的隔阂,让设计师更加有效率,也更易协作。

技术和设计的进步对比。

但 Figma 的真正潜力在于它能否过渡到成为一个平台。如果 Figma 能够做到,他们将推动设计作为一门学科的进步。

公司能否在一个领域取得成功是由很多因素决定的,其中最重要的是运气。

但当学科发生结构性变化时,那些蓬勃发展的公司就会产生巨大的影响力,他们在抽象层、社交规范、架构等做的决定对整一代具有巨大的影响。对于平台而言更是如此,平台的循环变成了整个生态系统的核心。对于像 Figma 这样承担这一重任的公司来说,这既是巨大的机遇,也是巨大的责任。

原文链接:https://kwokchain.com/2020/06/19/why-Figma-wins/


更多阅读


转载原创文章请添加微信:geekparker
继续滑动看下一个

您可能也对以下帖子感兴趣

文章有问题?点此查看未经处理的缓存